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            Presence and Instant Messaging Peering Use Cases

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This document describes several use cases of peering of non-VoIP
   (Voice over IP) services between two or more Service Providers.
   These Service Providers create a peering relationship between
   themselves, thus enabling their users to collaborate with users on
   the other Service Provider network.  The target of this document is
   to drive requirements for peering between domains that provide the
   non-VoIP based collaboration services with presence and, in
   particular, Instant Messaging (IM).
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1.  Introduction

   This document uses the terminology as defined in [1] unless otherwise
   stated.

   Real Time Collaboration (RTC) services have become as prevalent and
   essential for users on the Internet as email.  While RTC services can
   be implemented directly by users in a point-to-point fashion, they
   are often provided for, or on behalf of, a Peer Network of users
   within an administrative domain.  As the use of these services grows,
   users increasingly have the need to communicate with users not only
   within their own Peer Network but with those in other Peer Networks
   as well (similar to the old Public Switched Telephony Network (PSTN)
   that enabled global reachability).  In practice, each Peer Network is
   controlled by some domain, and so there is a need to provide for
   easier establishment of connectivity between Peer Networks and for
   the management of the relationships between the Peer Networks.  This
   document describes a set of use cases that describe how peering
   between Peer Networks may be used in non-VoIP RTC services.  The use
   cases are intended to help in identifying and capturing requirements
   that will guide and then enable a secure and easier peering between
   Peer Networks that provide non-VoIP RTC services.  The use cases for
   the VoIP RTC services are described in [2].

   Note that this document does not define requirements for a new
   protocol or for protocol extensions.  It captures the way that
   presence and Instant Messaging are currently used within enterprises
   and operator domains.

2.  Use Cases

2.1.  Simple Interdomain Subscription

   Assume two Peer Networks, Peer Network A and Peer Network B.  User
   Alice@example.com (hosted in Peer Network A) wants to subscribe to
   user Bob@example.net (hosted in Peer Network B) and get his presence
   information.  In order to do so, Alice@example.com could connect
   directly to example.net and subscribe to Bob's presence information.
   However, Peer Network B is willing to accept subscriptions and route
   IMs only when they are coming from its users or from other Peer
   Networks that Peer Network B trusts.

   In reality, what will happen is Peer Network A will connect to Peer
   Network B and send Alice's subscription to Bob via Peer Network B.
   When Peer Network B has new information on Bob, it will send
   notifications to Peer Network A, which will pass them to Alice.
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2.2.  List-Based Interdomain Subscription

   This is similar to the simple interdomain subscription use case,
   except in this case Alice subscribes to a Uniform Resource Identifier
   (URI) [8] that represents a list of users in Peer Network B [9] [3].

   There are several types of lists that Alice may subscribe to:

   o  Personal group - a list that is created and maintained by Alice
      and includes Alice's watch list.

   o  Public group - a list that is created and maintained by an
      administrator.  Public groups usually contain a list of specific
      people that have some common characteristic, e.g., support group
      of a company.

   o  Ad-hoc group - a list that is short lived and is usually created
      in the context of some activity that Alice is doing.  An ad-hoc
      group may be created by Alice or by some application.  Typical
      examples may be the list of people that participate with Alice in
      a conference or a game.

2.3.  Authorization Migration

      If many users from one Peer Network watch presentities [6] in
      another Peer Network, it may be possible that many watchers [6]
      from one Peer Network will subscribe to the same user in the other
      Peer Network.  However, due to privacy constraints that enable a
      user to provide different presence documents to different
      watchers, each Peer Network will have to send multiple copies of
      the watched-presence document.  The need to send multiple copies
      between the Peer Networks is very inefficient and causes redundant
      traffic between the Peer Networks.

      In order to make the subscription between Peer Networks more
      efficient there needs to be a way to enable Peer Networks to agree
      to share privacy information between them.  This will enable
      sending a single copy (the full copy) of the presence document of
      the watched user and letting the receiving Peer Network be
      responsible for sending the right values to the right watchers
      according to the delegated privacy policies of the watched users.

      Instead of sharing the watched user's privacy policies between the
      Peer Networks, it is also possible to send different copies of the
      presence document with a list of the watchers the presence
      document is intended for.  For example, if there is a set of
      watchers in one Peer Network that may see the location of the
      presentity and another set of users in the same Peer Network that



Houri, et al.                Informational                      [Page 3]

RFC 5344           Presence and IM Peering Use Cases        October 2008


      may not see the location information, two presence documents will
      be sent--each associated with a list of watchers that should
      receive it.  One presence document will contain the location
      information and will be associated with a list of users that may
      see it, and the other presence document will not contain the
      location information and will be associated with a list of users
      that may not see the location information. See [11].

2.4.  Pager Mode IM

      In this use case, a user from one Peer Network sends a pager mode
      [7] IM to a user on another Peer Network.

2.5.  Session Based IM

      In this use case, a user from one Peer Network creates a Message
      Session Relay Protocol (MSRP) [10] session with a user from
      another Peer Network.

2.6.  Other Services

      In addition to VoIP sessions, which are out of scope for this
      document, only presence and IM have been ratified as RFCs.  In
      addition to presence and IM, there are many other services that
      are being standardized or that may be implemented using minimal
      extensions to existing standards.  These include:

   o  N-way chat - enable a multi-participant textual chat that will
      include users from multiple Peer Networks.  See [4] for more
      details.

   o  File transfer - send files from a user in one Peer Network to a
      user in another Peer Network.  See [5] for more details.

   o  Document sharing - sharing and editing a document between users in
      different Peer Networks.

      Note: Document sharing is mentioned in this document only for
      completeness of use cases.  It is not being standardized by the
      IETF and will not be included in the requirements document that
      will result from this document.

   The list above is of course not exhaustive, as new developments in
   the world of non-VoIP RTC will surface new services.  Enabling
   peering between networks for some of the services will create a basis
   for enabling peering for future services also.
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2.7.  Federation and Clearing House

   A federation as defined in [1] enables peering between multiple Peer
   Networks.  A federation may be implemented by means of a central
   service providing a hub for the Peer Networks or, alternatively, Peer
   Networks may connect to each other in a peer-to-peer fashion.  One of
   the most important services that this hub type of federation should
   provide is authorized interconnection that enables each Peering
   Network to securely identify other Peering Networks.  Other services
   that might be provided include an N-way chat server, lawful
   interception, logging, and more.  This hub type of federation is also
   known as a "Clearing House".

   As non-VoIP services are usually text-based and consume less
   bandwidth, they may benefit from having a central service that will
   do central services such as logging for them.  For example, instead
   of requiring each Peer Network to log all messages that are being
   sent to the other Peer-Network, this service can be done by the
   Clearing House.

3.  Security Considerations

   When Peer Network A peers with Peer Network B, there are several
   security issues for which the administrator of each Peer Network will
   need mechanisms to verify:

   o  All communication channels between Peer Networks and between each
      Peer Network and the Clearing House have their authenticity and
      confidentiality protected.

   o  The other Peer Network is really the Peering Network that it
      claims to be.

   o  The other Peer Network is secure and trustworthy, such that
      information that is passed to it will not reach a third party.
      This includes information about specific users as well as
      information about the authorization policies associated with user
      information.

   o  The other Peer Network is secure and trustworthy, such that it
      will not modify or falsify data that it presents to its users
      except as required by the authorization policy provided.

   o  If there is a third party (e.g., a Clearing House) involved in the
      connection between the two Peering Networks that element is also
      secure.
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   The same issues of security are even more important from the point of
   view of the users of the Peer Networks.  Users will be concerned
   about how their privacy is being adhered to when their presence
   information is sent to the other Peer Network.  Users today are
   concerned about providing their email address to a third party when
   they register to a domain; presence contains much more sensitive
   information, and the concern of users here will be even greater.

   The privacy issue is even harder when we take into account that, in
   order to enable scalable peering between big Peer Networks, there are
   some optimizations that may require migration of the privacy
   definitions of users between Peer Network (see Section 2.3).  We can
   imagine the fiasco that would ensue if a user of one Peer Network
   were able to see the privacy information and learn he/she is listed
   in the block list of a close friend.

   This document discusses use cases for peering between Peer Networks.
   It is out of the scope of this document to provide solutions for
   security.  Nevertheless, it is obvious that the protocols that will
   enable the use cases described here will have to provide for the
   security considerations also described here.
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